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ABSTRACT 



A software package manager uses a distribution unit con- 
taining components for a software package and a manifest 
file that describes the distribution unit to manage the instal- 
lation, execution, and uninstallation of software packages on 
a computer. Information in the manifest file pertaining to a 
software package is stored in a code store data structure 
upon installation of the package. The manifest file also 
contains information that permits the software package 
manager to resolve any software dependencies upon instal- 
lation. The software package manager uses the code store 
data structure to locate the required components when the 
software is executed and to remove the components appro- 
priately when the software is uninstalled. 
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SOFTWARE PACKAGE MANAGEMENT 

CROSS REFERENCE TO RELATED 
APPLICATIONS 

[0001] This application is a continuation of Forbes et al., 
U.S. patent application Ser. No. 09/099,570, filed Jun. 19, 
1998, entitled, "Software Package Management/' which is 
hereby incorporated herein by reference. 

[0002] This application is related to U.S. patent applica- 
tion Ser. No. 08/764,040, entitled AUTOMATIC SOFT- 
WARE DOWNLOADING FROM A COMPUTER NET- 
WORK, filed on Dec. 12, 1996, and assigned to the assignee 
of the present application. 

COPYRIGHT NOTICE/PERMISSION 

[0003] A portion of the disclosure of this patent document 
contains material subject to copyright protection. The copy- 
right owner has no objection to the facsimile reproduction 
by anyone of the patent document or the patent disclosure as 
il appears in the Patent and Trademark Office patent file or 
records, but otherwise reserves all copyright rights whatso- 
ever. The following notice applies to the software and data 
as described below and in the drawing hereto: Copyright© 
1997, Microsoft Corporation, All Rights Reserved. 

FIELD OF THE INVENTION 

[0004] This invention relates generally to software distri- 
bution, and more particularly to the management of software 
packages after distribution. 

BACKGROUND OF THE INVENTION 

[0005] Historically, the primary medium for software dis- 
tribution has been either the traditional floppy disk or the 
more recent compact disc (CD-ROM). However, more and 
more individuals are acquiring software by downloading it 
from remote server computers connected to the client com- 
puters through the Internet. Additionally, companies and 
organizations are distributing software to their users across 
their local area networks. The physical medium is the 
network cable itself and the supporting communication 
hardware, a fixed cost associated with the establishment of 
the network. Therefore, distributing and installing software 
over an existing network bypasses the cost overhead of 
producing CDs or floppy disks. 

[0006] In addition, using the network as the distribution 
medium profoundly reduces the software's total cost of 
ownership to an extent that cannot be achieved by CDs or 
floppies even when the media cost almost nothing to manu- 
facture. Software distribution via CDs and floppies obey the 
"pull" paradigm, where every action is user-initiated. Dis- 
tribution over the network has the ability to apply a "push" 
paradigm which provides three main benefits. 

[0007] First, the installation is "hands-free" in that the user 
does not have to manually install the software. Second, the 
software can be easily and timely upgraded from a desig- 
nated location because the burden of upgrading is borne by 
the software itself. Third, because different types of com- 
puter hardware and operating systems can connect to a 
common network, software distributed over the network can 
be made to work across platforms or intelligent so that only 
the correct version of platform-specific software is pushed 
down to the user. 



[0008] However, current methods of software distribution 
over a network do not fully exploit the benefits. Existing 
distribution of platform-specific, or "native code," software 
relies on installation file formats that are hard to create, not 
extensible, and specific to a particular operating system. 
Although most current software is written in modules, there 
is no current mechanism that handles the situation where one 
component in a software program requires the presence of 
another to operate. If a user downloads software from a Web 
page, the user may discover that the program requires an 
external library which necessitates another network session 
to download, assuming the user can find the right location, 
and then the user must manually install the library before 
installing the software. 

[0009] Software programs written in the popular platform- 
independent Java language require that the Java classes be 
"packaged" for distribution but the package does not contain 
persistent information so once Java software is installed on 
a client computer, all information about it is lost. It is 
impossible to tell what the version number is, where it came 
from, or whom the author is. Additionally, the current 
network distribution methods make it difficult to digitally 
sign a Java package for security purposes. 

[0010] More problems arise when a user wants to execute 
an application which depends on both native code compo- 
nents and Java components since the distribution methods 
are completely different. Finally, once the software is down- 
loaded and successfully installed on the client computer, no 
mechanism exists to track all of the components so that older 
versions can be easily superceded when newer version are 
available or that all the related components can be readily 
uninstalled when necessary. 

[00U] Therefore, there is a need for a software distribu- 
tion and tracking mechanism that handles cross-platform 
software, specifies the component dependencies, and is 
applicable to both the older distribution media as well as to 
the network distribution paradigm. 

SUMMARY OF THE INVENTION 

[0012] The above-mentioned shortcomings, disadvan- 
tages and problems are addressed by the present invention, 
which will be understood by reading and studying the 
following specification. 

[0013] A software package manager uses a distribution 
unit containing components for a software package and a 
manifest file that describes the distribution unit to manage 
the installation, execution, and uninstallation of software 
packages on a computer. For installation, the package man- 
ager acquires the manifest file and parses it to learn if the 
software package depends on any additional components. 
The package manager resolves any dependencies by acquir- 
ing a distribution unit containing the needed component and 
installs the dependency's distribution unit as described 
below. Because dependencies can nested within dependen- 
cies, the package manager recursively processes all the 
dependencies before finishing the installation of the software 
package that depends upon the additional components. 

[0014] The software package manager acquires the distri- 
bution unit and extracts the components in the distribution 
unit into a directory on the computer. The package manager 
causes the operating system of the computer to install the 
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software. The package manager then updates a code store 
data structure with information in the manifest file. The 
fields in the code store data structure contains such infor- 
mation as the name and version of the distribution unit, a list 
of the components and their location on the computer, and 
the source of the distribution unit Additional fields in the 
code store data structure can also contain a component 
version, a component data type, and a digital signature if one 
was affixed to the distribution unit. 

[0015] During the installation, the package manager can 
optionally scan the code store data structure to determine if 
a component to be installed already exists on the computer 
and updates the code store data structure with the location of 
the later version of the component. 

[0016] When a user requests execution of software, the 
package manager uses the code store data structure to locate 
the appropriate components for the operating system to use. 
When the user requests the uniostallation of a software 
package, the package manager deletes the appropriate com- 
ponents from the computer and updates the code store data 
structure accordingly. 

[0017] The manifest file and distribution unit optionally 
are combined into a distribution unit file. 

[0018] The manifest file format is common across all types 
of code and operating systems and easily extended to 
embrace new code types are they arise. The manifest file and 
distribution unit can be stored on all types of media from 
traditional magnetic and optical disks to networked servers. 
The distribution units for dependencies do not have to reside 
on the same type of media as the distribution unit or the 
manifest file that refers to the dependency. More than one 
distribution unit can be resident in a distribution unit file and 
a distribution unit file can contain a mixture of distribution 
units containing different code types. 

[0019] Thus, the software package manager, the manifest 
file, the distribution unit and the code store data structure of 
the present invention solve the problems with existing 
distribution mechanisms. The manifest file is not particular 
to a particular code type or operating system and allows for 
the specification of nested software dependencies. Because 
the manifest file contains the location of the distribution 
units for any dependencies, the software package manager 
can acquire and install the dependencies without requiring 
manual intervention by the user. Different types of distribu- 
tion units can be mixed in a distribution unit file so that a 
single mechanism is used to acquire and install all types of 
code. 

[0020] The code store data structure maintained by the 
software package manage contains information about the 
installed software such as version and installation location, 
and is used to resolve version discrepancies among software 
programs that share components. The code store data struc- 
ture is used by the package manager to locate necessary 
component when the software is executed so that a compo- 
nent stored in one directory can be readily shared by 
software programs with components in different directories. 
Finally, the code store data structure eases the uninstallation 
process by centralizing all the information about installed 
components. 

[0021] The present invention describes systems, clients, 
servers, methods, and computer-readable media of varying 



scope. In addition to the aspects and advantages of the 
present invention described in this summary, farther aspects 
and advantages of the invention will become apparent by 
reference to the drawings and by reading the detailed 
description that follows. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0022] FIG. 1 shows a diagram of the hardware and 
operating environment in conjunction with which embodi- 
ments of the invention may be practiced; 

[0023] FIGS. 2A, 2B and 2C are diagrams illustrating a 
system-level overview of an exemplary embodiment of a 
package manager of the invention; 

[0024] FIGS. 3A, 3B, 3C and 3D are flowchart of methods 
to be performed by a client according to an exemplary 
embodiment of the package manager of the invention; and 

[0025] FIG. 4 is a diagram of an exemplary embodiment 
of an entry in a code store data structure suitable for use by 
the methods shown in FIGS. 3A, 3B and 3C. 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0026] In the following detailed description of exemplary 
embodiments of the invention, reference is made to the 
accompanying drawings which form a part hereof, and in 
which is shown by way of illustration specific exemplary 
embodiments in which the invention may be practiced. 
These embodiments are described in sufficient detail to 
enable those skilled in the art to practice the invention, and 
it is to be understood that other embodiments may be utilized 
and that logical, mechanical, electrical and other changes 
may be made without departing from the spirit or scope of 
the present invention. The following detailed description is, 
therefore, not to be taken in a limiting sense, and the scope 
of the present invention is defined only by the appended 
claims. 

[0027] The detailed description is divided into five sec- 
tions. In the first section, the hardware and the operating 
environment in conjunction with which embodiments of the 
invention may be practiced are described. In the second 
section, a system level overview of the invention is pre- 
sented. In the third section, methods for an exemplary 
embodiment of the invention are provided. In the fourth 
section, a particular Open Software Description implemen- 
tation of the invention is described. Finally, in the fifth 
section, a conclusion of the detailed description is provided. 

[0028] Hardware and Operating Environment 

[0029] FIG. 1 is a diagram of the hardware and operating 
environment in conjunction with which embodiments of the 
invention may be practiced. The description of FIG. 1 is 
intended to provide a brief, general description of suitable 
computer hardware and a suitable computing environment in 
conjunction with which the invention may be implemented. 
Although not required, the invention is described in the 
general context of computer-executable instructions, such as 
program modules, being executed by a computer, such as a 
personal computer. Generally, program modules include 
routines, programs, objects, components, data structures, 
etc., that perform particular tasks or implement particular 
abstract data types. 
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[0030] Moreover, those skilled in the art will appreciate 
that the invention may be practiced with other computer 
system configurations, including hand-held devices, multi- 
processor systems, microprocessor-based or programmable 
consumer electronics, network PCs, minicomputers, main- 
frame computers, and the like. The invention may also be 
practiced in distributed computing environments where 
tasks are performed by remote processing devices that are 
linked through a communications network. In a distributed 
computing environment, program modules may be located 
in both local and remote memory storage devices. 

[0031] The exemplary hardware and operating environ- 
ment of FIG. 1 for implementing the invention includes a 
general purpose computing device in the form of a computer 
20, including a processing unit 21, a system memory 22, and 
a system bus 23 that operatively couples various system 
components, including the system memory 22, to the pro- 
cessing unit 21. There may be only one or there may be more 
than one processing unit 21, such that the processor of 
computer 20 comprises a single central-processing unit 
(CPU), or a plurality of processing units, commonly referred 
to as a parallel processing environment. The computer 20 
may be a conventional computer, a distributed computer, or 
any other type of computer; the invention is not so limited. 

[0032] The system bus 23 may be any of several types of 
bus structures including a memory bus or memory control- 
ler, a peripheral bus, and a local bus using any of a variety 
of bus architectures. The system memory may also be 
referred to as simply the memory, and includes read only 
memory (ROM) 24 and random access memory (RAM) 25. 
A basic input/output system (BIOS) 26, containing the basic 
routines that help to transfer information between elements 
within the computer 20, such as during start-up, is stored in 
ROM 24. The computer 20 further includes a hard disk drive 
27 for reading from and writing to a hard disk, not shown, 
a magnetic disk drive 28 for reading from or writing to a 
removable magnetic disk 29, and an optical disk drive 30 for 
reading from or writing to a removable optical disk 31 such 
as a CD ROM or other optical media. 

[0033] The hard disk drive 27, magnetic disk drive 28, and 
optical disk drive 30 are connected to the system bus 23 by 
a hard disk drive interface 32, a magnetic disk drive inter- 
face 33, and an optical disk drive interface 34, respectively. 
The drives and their associated computer-readable media 
provide nonvolatile storage of computer-readable instruc- 
tions, data structures, program modules and other data for 
the computer 20. It should be appreciated by those skilled in 
the art that any type of computer-readable media which can 
store data that is accessible by a computer, such as magnetic 
cassettes, flash memory cards, digital video disks, Bernoulli 
cartridges, random access memories (RAMs), read only 
memories (ROMs), and the like, may be used in the exem- 
plary operating environment. 

[0034] A number of program modules may be stored on 
the hard disk, magnetic disk 29, optical disk 31, ROM 24, or 
RAM 25, including an operating system 35, one or more 
application programs 36, other program modules 37, and 
program data 38. A user may enter commands and informa- 
tion into the personal computer 20 through input devices 
such as a keyboard 40 and pointing device 42. Other input 
devices (not shown) may include a microphone, joystick, 
game pad, satellite dish, scanner, or the like. These and other 



input devices are often connected to the processing unit 21 
through a serial port interface 46 that is coupled to the 
system bus, but may be connected by other interfaces, such 
as a parallel port, game port, or a universal serial bus (USB). 
A monitor 47 or other type of display device is also 
connected to the system bus 23 via an interface, such as a 
video adapter 48. In addition to the monitor, computers 
typically include other peripheral output devices (not 
shown), such as speakers and printers. 

[0035] The computer 20 may operate in a networked 
environment using logical connections to one or more 
remote computers, such as remote computer 49. These 
logical connections are achieved by a communication device 
coupled to or a part of the computer 20; the invention is not 
limited to a particular type of communications device. The 
remote computer 49 may be another computer, a server, a 
router, a network PC, a client, a peer device or other 
common network node, and typically includes many or all of 
the elements described above relative to the computer 20, 
although only a memory storage device 50 has been illus- 
trated in FIG. 1. The logical connections depicted in FIG. 
1 include a local-area network (LAN) 51 and a wide-area 
network (WAN) 52. Such networking environments are 
commonplace in offices, enterprise-wide computer net- 
works, intranets and the Internet. 

[0036] When used in a LAN-networking environment, the 
computer 20 is connected to the local network 51 through a 
network interface or adapter 53, which is one type of 
communications device. When used in a WAN-networking 
environment, the computer 20 typically includes a modem 
54, a type of communications device, or any other type of 
communications device for establishing communications 
over the wide area network 52, such as the Internet. The 
modem 54, which may be internal or external, is connected 
to the system bus 23 via the serial port interface 46. In a 
networked environment, program modules depicted relative 
to the personal computer 20, or portions thereof, may be 
stored in the remote memory storage device. It is appreciated 
that the network connections shown are exemplary and other 
means of and communications devices for establishing a 
communications link between the computers may be used. 
[0037] The hardware and operating environment in con- 
junction with which embodiments of the invention may be 
practiced has been described. The computer in conjunction 
with which embodiments of the invention may be practiced 
may be a conventional computer, a distributed computer, or 
any other type of computer; the invention is not so limited. 
Such a computer typically includes one or more processing 
units as its processor, and a computer-readable medium such 
as a memory. The computer may also include a communi- 
cations device such as a network adapter or a modem, so that 
it is able to communicatively couple to other computers. 
[0038] System Level Overview 

[0039] A system level overview of the operation of an 
exemplary embodiment of the invention is described by 
reference to FIGS. 2A, 2B and 2C. The exemplary embodi- 
ment is implemented in an wide-area networking environ- 
ment 52 having a server computer, such as remote computer 
49 and a user or client computer, such as local computer 20, 
all of which are shown in FIG. 1 and described in the 
previous section. 

[0040] Fred's Software Company has written a software 
package named "CoolestApp" that runs as a "plug-in appli- 
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cation" in a World Wide Web browser, such as Microsoft 
Internet Explorer 4. A plug-in application is often employed 
to provide additional capabilities, such as multimedia or 
interactive controls, to browsers. One type of control appli- 
cation is that written to conform with Microsoft's ActiveX 
specifications. The plug-ins are usually written in object- 
oriented languages such as C++ or Java and are typically 
used on Web pages. The user may be prompted to download 
the plug-in or it may be automatically downloaded when 
needed. 

[0041] Referring to FIG. 2A, Fred's Software Company 
wants to distribute the CoolestApp over the Internet from 
Fred's Software Company's Web server 201 to a user's 
computer 203. Fred's Software Company logically groups 
the components for the CoolestApp together into a "distri- 
bution unit"209. The components can include platform- 
specific compiled binary files such as dynamic linking 
library (.dll) files used by the Microsoft Windows family of 
operating systems, Java bytecode (.class) files, or files that 
contain optional installation instructions for how to use 
certain components contained in the distribution unit, for 
example, ActiveX controls may need to be registered before 
use. The distribution unit 209 can be a separate file or can be 
a portion of a "distribution unit file"205 as explained below. 

[0042] Fred's Software Company also creates a "mani- 
fest" file 207 describing the CoolestApp. The CoolestApp 
manifest file 207 contains information about CoolestApp, 
including the name of the CoolestApp distribution unit 209, 
the version number of the software package (all components 
in the distribution unit 209 have the same version number in 
this embodiment), and the operating systems under which 
the CoolestApp executes. Fred's Software Company 
bundles the CoolestApp distribution unit 209 and manifest 
file 207 into a distribution unit file 205 for storage on the 
server 201. 

[0043] The names of other files in the distribution unit file 
205, such as a text file containing licensing information or 
a "readme" file containing special instructions for the soft- 
ware package, are listed in the manifest file 207. The 
manifest file 207 also contains entries for software that is 
required to run CoolestApp but which is not included in the 
distribution unit file 205. Such required software represent 
"dependencies" and frequently include such items as lan- 
guage libraries and common object class libraries. A depen- 
dency can also be another software package. The manifest 
file 207 provides the ability to describe the software depen- 
dencies in a recursive tree format, also known as a "directed 
graph." 

[0044] in the present example, CoolestApp is an enhanced 
version of a software program named "CoolApp" previously 
distributed by Fred's Software Company. Rather than com- 
pletely rewriting CoolestApp, Fred's Software Company 
used the CoolApp components as a base and created addi- 
tional components for the new features in CoolestApp. In the 
interest of minimizing download time, Fred's Software 
Company does not include the original components for 
CoolApp in the CoolestApp distribution unit 205. Instead 
Fred's Software Company inserts a dependency entry in the 
manifest file 205 which directs a user's browser to the 
location on Fred's Software Company server 201 holding 
the distribution unit file 215 for CoolApp as illustrated in 
FIG. 2B. 



[0045] The browser begins the installation of the Coole- 
stApp software package to the local computer by download- 
ing the CoolestApp distribution unit file 205. A software 
package manager 211 running in the underlying operating 
system on the user's computer 203 extracts the manifest file 
207 from the distribution unit file 209 and accesses an 
installed package database 213 to feterrnine that Fred's 
Software Company's CoolestApp is not already installed. 
The dependency entry in CoolestApp manifest file 207 alerts 
the package manager 211 that the CoolestApp depends on 
Fred's Software Company's CoolApp. The package man- 
ager 211 determines that CoolApp has not been previously 
installed and directs the browser to download the CoolApp 
distribution unit file 215 from the server location specified in 
the dependency entry. 

[0046] Once the CoolApp distribution unit file 215 has 
been downloaded to the user's computer 203, the package 
manager extracts the CoolApp manifest file 217 and deter- 
mines that CoolApp does not have any dependencies. The 
package manager 211 creates a private directory 221 for 
Fred's Software Company applications, named FSC, 
extracts the CoolApp components from the distribution unit 
219 into the FSC directory, and calls the underlying oper- 
ating system installation facility to install the CoolApp 
components. The package manager 211 registers the Cool- 
App components in the installed package database 213 when 
the installation is successful. 

[0047] Referring to FIG. 2C, the package manager 213 
extracts the CoolestApp components from the CoolestApp 
distribution unit 209 to the FSC directory 221, calls the 
installation facility, and registers the CoolestApp compo- 
nents in the installed package database 213. The browser 
now can run the CoolestApp helper application from the 
FSC directory 221. 

[0048] If the user downloads additional Fred's Software 
Company applications that depend upon the components in 
either CoolApp or CoolestApp, the package manager 211 
will use the already installed components to satisfy any 
dependencies that reference installed software package 
unless the additional applications require versions later than 
that installed. 

[0049] If after running the CoolestApp helper application, 
the user decides that CoolestApp is not needed, the user 
employs the underlying operating systems uninstall facility 
to uninstall CoolestApp. The uninstall facility invokes the 
package manager 211 which determines if the CoolApp and 
CoolestApp components are being used by other applica- 
tions and deletes the software packages from the FSC 
directory 221 if not. The package manager 211 also deletes 
the package entries from the installed package database 213 
when the packages have been deleted from the FSC direc- 
tory 221. 

[0050] The system level overview of the operation of an 
exemplary embodiment of the invention has been described 
in this section of the detailed description. The package 
manager and its supporting files have been described in 
relation to installing a software package having a single 
dependency. While the invention is not limited to any 
particular distribution media, for sake of clarity a simplified 
version of Internet software distribution has been described. 
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[0051] Methods of an Exemplary Embodiment of the 
Invention 

[0052] In the previous section, a system level overview of 
the operation of an exemplary embodiment of the invention 
was described. In this section, the particular methods per- 
formed by a client or local computer of such an exemplary 
embodiment are described by reference to a series of flow- 
charts. The methods to be performed by the client computer 
constitute computer programs made up of computer-execut- 
able instructions. Describing the methods by reference to a 
flowchart enables one skilled in the art to develop such 
programs including such instructions to carry out the meth- 
ods on suitable computerized clients (the processor of the 
clients executing the instructions from computer-readable 
media). 

[0053] The software package manager of the present 
invention is described as providing three major functions to 
the runtime environment of the local computer on which it 
runs as illustrated in FIGS. 3A-3D. It manages the installa- 
tion of software packages, it locates necessary components 
when software is executed, and it supports the uninstallation 
of software. The package manager uses the installed package 
database, also called a "code store" data structure, to track 
components of software packages that have been installed 
on the local computer. One of skill in the art will, upon 
reading the following description of the code store data 
structure, recognize that any type of organized data struc- 
ture, including various type of data bases, is suitable for use 
with the package manager. 

[0054] As in the exemplary embodiment described in the 
previous section, the manifest file contains dependency 
entries specifying locations of distribution units containing 
required software components. The distribution unit file is 
suitable for distributing software packages on traditional 
media, such as CD-ROM or floppy disk, as well as over a 
wide area network, such as the Internet. The package man- 
ager extracts the manifest file and the distribution unit from 
the distribution unit file. In an alternate embodiment, the 
distribution unit and the manifest file can be stored sepa- 
rately on a network and the manifest file contains the 
network location of its corresponding distribution unit. 

[0055] Installation 

[0056] Referring first to FIGS. 3A and 3B, a flowchart of 
methods to be performed by a client according to an exem- 
plary embodiment of the invention when installing new 
software is shown. This method is inclusive of the steps or 
acts required to be taken by the package manager. 

[0057] When the distribution unit file for a software pack- 
age is loaded onto a computer for installation, the software 
package manager running in the computer acquires the 
manifest file for processing (step 301). In an embodiment in 
which the manifest file is distributed in a distribution unit 
file, the package manager acquires the distribution unit file 
and extracts the manifest file from the distribution unit file. 
The package manager checks the name and version of the 
software package contained in the manifest file against the 
code store data structure to determine if the software pack- 
age has already been installed (step 303). If so, the package 
manager exits (step 321). 

[0058] If the software package is not installed, the package 
manager checks the manifest file to determine if the software 



package requires the installation of other software compo- 
nents (dependencies) not supplied as part of the distribution 
file unit (step 305) before installing the software package 
from the distribution unit. Such is frequently the case when 
a software package is written in a common programming 
language such as Java or C++ which depend on object class 
or language libraries being present. 

[0059] If there are dependencies, the package manager 
checks the code store data structure to determine if the 
dependencies are installed on the local computer (step 327). 
If not, the package manager uses information stored in the 
manifest file about the dependencies to locate a source for 
the dependencies. The package manager than acquires a 
dependency from the source specified in the manifest file 
(step 329). In one embodiment, the source is a remote server 
designated by a uniform resource locator (URL) path name. 
In an alternate embodiment, the source is a server on a local 
area network and the path name is a network drive. 

[0060] After acquiring the dependency from the source, 
the package manager installs the dependent software com- 
ponents on the local computer. The installation of the 
dependent components is identical to the installation process 
for the original software package which will be described in 
detail below in conjunction with steps 307 through 325. 
Because each dependency can itself include dependencies, 
the package manager will install all the nested dependencies 
prior to finishing the installation of the original software 
package. 

[0061] Once all Ihe dependencies are installed, the pack- 
age manager determines if a directory for the software 
package exists (step 307) and creates one if it does not (step 
309). The package manager assigns the directory a unique 
name that has a high probability of being different for every 
computer on which the software package is installed. In one 
embodiment, the unique name is generated using a standard 
hashing algorithm having the software package name as 
input. 

[0062] The package manager extracts the components for 
the software package from the distribution unit file into the 
directory (step 311). In one embodiment, the components are 
gathered into an uncompressed "zip" formatted data file 
which contains a directory of the files within it. Other 
embodiments which use similar file structures to group the 
components together with a directory structure will be 
readily apparent to one skilled in the art. The package 
manager then invokes the installation facility provided by 
the operating system to install the components (step 313). 

[0063] When the installation is successful (step 315), the 
package manager updates the code store data structure with 
the information contained in the manifest file (step 317 and 
FIG. 3B). 

[0064] The package manager creates an entry in the code 
store data structure for the software package that includes 
the name of the software package, the version number, and 
the name of the directory (step 331). The names of the 
components in the software package are stored in the 
corresponding software package entry in code store data 
structure (step 333). 

[0065] In one alternate embodiment shown in FIG, 3B, as 
part of the update process for the code store data structure, 
the package manager scans the code store data structure to 
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determine if any of the components in the software package 
arc shared with other software packages registered in the 
code store data structure (step 335). If so, the package 
manager performs one of three basic actions depending on 
the version information stored in the code store data base 
entries for the component (step 337). 

[0066] If the newly stored component is a newer version 
of the previously stored component (step 339) and the code 
store data structure entry for the previously installed soft- 
ware package that references the older version does not 
indicate it is version dependent (step 341), the package 
manager removes the older version from the directory in 
which it is stored (step 343) and updates the code store data 
structure entry for the previously installed software package 
to point to the newer version (step 345). If there is a version 
dependency noted, the package manager leaves the older 
version in the directory (step 347). 

[0067] If the newly stored component is older that the 
previously stored component (step 349) and the software 
package does not indicate a version dependency (step 351), 
the package manager removes the older version from the 
newly created directory (step 353) and updates the code 
store data structure entry for the newly installed software 
package to point to the newer version (step 355). As before, 
if there is a version dependency noted, the package manager 
does nothing to the older version (step 347). 

[0068] If the components are the same version, the pack- 
age manager chooses one to remove from its directory (step 
359) and updates the corresponding entry to point to the 
other component (step 361). 

[0069] In the embodiment in which the components are 
stored in an uncompressed zip file, or the like, the package 
manager uses the file directory to find the component to be 
deleted within the file in the appropriate directory. The 
package manager can, alternately, actually delete the com- 
ponent from the file and update the file directory or mark the 
component entry in the file directory as deleted depending 
on the particular file structure employed to hold the com- 
ponents. 

[0070] In an alternate embodiment, the package manager 
does not attempt to determine if there are mismatched 
versions installed and each software package uses the ver- 
sion of the component that is indicated by its entry in the 
code store data structure. 

[0071] Execution 

[0072] Referring next to FIG. 3C, a flowchart of a method 
to be performed by a client computer according to an 
exemplary embodiment of the invention when a software 
package registered through the package manager is executed 
in the runtime environment is shown. This method is inclu- 
sive of the steps or acts required to be taken by the software 
package manager. 

[0073] When the user requests execution of the software 
package, the runtime environment invokes the package 
manager (step 370) to locate the components necessary to 
run the software. The package manager matches the soft- 
ware package name to the corresponding entry in the code 
store data structure (step 371) to determine the directory, or 
directories, holding the components (step 373). In the 
embodiment in which the components are stored in an 



uncompressed zip file, or the like, the package manager uses 
the directory to find the particular components within the 
file. The package manager returns the location of the com- 
ponents to the runtime environment (step 375). 

[0074] Uninstall 

[0075] Finally, referring to FIG. 3D, a flowchart of a 
method to be performed by a client computer according to 
an exemplary embodiment of the invention when a software 
package registered through the package manager is unin- 
stalled is shown. This method is inclusive of the steps or acts 
required to be taken by the software package manager. 

[0076] When the user wants to uninstall a software pack- 
age from the local computer, a standard uninstall routine 
provided by the runtime environment invokes the package 
manager to update the code store data structure accordingly 
(step 380). The package manager removes the correspond- 
ing software package entry in the code store data structure 
(step 381). The package manager does not delete a compo- 
nent from the directory unless no other installed software 
package references it (step 383). 

[0077] In one embodiment, the package manager scans 
every entry in the code store data structure to determine if 
another the entry for another software package references 
the local directory holding the component in question. In a 
first alternate embodiment, the package manager creates and 
maintains a tree structure of all shared components, so it can 
quickly determine if the component is shared with another 
software package. In a second alternate embodiment, the 
component is not deleted at the time the software package is 
uninstalled but instead a "garbage collection" routine is 
periodically run by the package manager. The garbage 
collection routine uses the code store data structure to 
determine if a component is referenced by any of the 
software packages installed on the local computer. Those 
components which are not referenced are then deleted. 

[0078] Code Store Data Structure 

[0079] FIG. 4 illustrates an exemplary embodiment of an 
entry in the code store data structure 400 suitable for use by 
the methods of the exemplary embodiments of the package 
manager described above. Each entry contains, at a mini- 
mum, five fields: a name field 401 for the distribution unit, 
a version field 403 for the distribution unit, a component 
field 405 that contains a list of the components in the 
distribution unit, a location field 407 that contains the 
location of the components on the client computer, and a 
source field 409 that contains a pointer to the source of the 
distribution unit, such as a URL for a downloaded distribu- 
tion unit. If a component is a platform -specific ("native 
code") file, such as a Microsoft Windows DLL, the file name 
is the component is stored in the component field. If a 
component is a package of Java classes, the component field 
contains the name of the Java package. In the case of a Java 
package, the code store entry has the following additional 
fields: a component version field 411 (which may be differ- 
ent from the version of the distribution unit; both are used by 
the package manager in resolving version dependencies), 
and a component type field 413 that indicates what type of 
Java classes the package contains, i.e., system, application, 
etc., both shown in phantom in FIG. 4 An optional data 
signature field 415, also shown in phantom, contains a 
digital signature affixed to the distribution unit, if it was 
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signed. As well be familiar to one of skill in the art, the 
digital signature itself can contain security attributes about 
the package. The security attributes can be used by the 
package manager to prevent versions updates from a source 
other than the signer. Furthermore, a vendor may include 
software packages from third parlies as dependencies in the 
distribution unit and the package manager uses the digital 
signatures on each dependent package to direct the corre- 
sponding components into different local directories. 

[0080] In one embodiment of the code store data structure 
implemented in the Microsoft Windows environment, the 
system registry file is used as the repository for the code 
store entries and the package manager accesses the entries 
through the standard registry interface provided by the 
operating system. 

[0081] Summary 

[0082] The particular methods performed by the package 
manager of an exemplary embodiment of the invention have 
been described. The method performed by the package has 
been shown by reference to flowcharts including the steps 
from 300 to 355 during installation of a software package, 
the steps 370 to 375 during execution of a software package, 
and steps 380-385 during uninstallation of a software pack- 



age. Additionally, an exemplary embodiment of a code store 
data structure has been described. 

[0083] Open Software Description Implementation 

[0084] In this section of the detailed description, a par- 
ticular implementation of the invention is described that 
formats the manifest file using an Open Software Descrip- 
tion (OSD) format. OSD specifies a vocabulary used for 
describing software packages and their dependencies for 
client computers which is a subset of the Extensible Markup 
Language (XML). XML is similar to the Hypertext Markup 
Language (HTML) used to write Web pages and provides a 
general method of representing structured data in the form of 
lexical trees. Using the XML model, markup tags in the 
OSD vocabulary are represented as elements of a tree. The 
three basic relationships between elements are "parent-of, 
" w child-of, w and "sibling-of." Distant relationships can be 
formed from recursive applications of the three basic ones. 
The basic XML elements that compose the OSD format are 
shown in Table 1 below. Additional information on the OSD 
vocabulary can be found in the Specification for the Open 
Software Description (OSD) Format published on Aug. 11, 
1997, and available for download from either Microsoft 
Corporation or Marimba, Inc. 



TABLE 1 



Element ABSTRACT 



Content 
Child of 
Element 
Attributes 



Child of 
Element 
Attributes 



Child of 
Patent of 
Element 
Attributes 

Child of 
Element 
Attributes 
Child of 
Parent of 

Element 

Attribute 

Child of 

Element 

Attributes 

Child of 

Element 

Attributes 

Child of 

Element 

Attributes 

Child of 
Element 
Attributes 
Child of 



<string> 

SOFTPKG 

CODEBASE 

SIZE-<max-KB> - the maximum allowable size for the software archive file. 
"Kilobytes" is the unit of measure. If SIZE is exceeded, then the software will not be 
downloaded. 

HREF-<URL> « points to the archive to be downloaded. 

FILENAME- <string> - specifies a file contained within the same archive as the 

OSD. If the OSD is used as a stand-alone file, then this attribute is ignored. 

IMPLEMENTATION 

DEPENDENCY 

ACTION- (Assert | Install) - Assert means: Ignore thia SOFTPKG entirely if the 

dependency is not already present on the client's machine. Install means: If the 

dependency is not already present on the client's machine, go get it, then install it, 

so that the SOFTPKG has all the pieces it needs. 

SOFTPKG, IMPLEMENTATION 

SOFTPKG 

DISKSIZE 

VALUE- <KB-mimber> -- approximate minimum number of bytes of disk space 

required by this implementation. "Kilobytes" is the unit of measure. 

IMPLEMENTATION 

IMPLEMENTATION 

None Supported 

SOFTPKG 

CODEBASE, DEPENDENCY, DISKSIZE, IMPLTYPE, LANGUAGE, OS, 

PROCESSOR, VM 

IMPLTYPE 

VALU E= <slring> — the type of the implementation. 

IMPLEMENTATTON 

LANGUAGE 

VALUE- <string> — uses language codes as specified in ISO 639. 

IMPLEMENTATION 

LICENSE 

HREF 

SOFTPKG 

MEMSIZE 

VALUE » <KB-number> approximate minimum number of bytes of memory required 
by this implementation during execution. "Kilobytes" is the unit of measure. 
IMPLEMENTATION 
OS 

VALUE- <string> - see Appendix B for a list of possible values. 
IMPLEMENTATION 
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TABLE 1 -continued 



Element ABSTRACT 



Element 
Attributes 
Child of 
Element 
Attributes 
Child of 
Element 
Attributes 



Child of 
Parent of 
Element 
Content 
Child of 
Element 
Attributes 
Child of 



OSVERSION 

VALUE»<string> 

OS 

PROCESSOR 

VALUE" <string> - see Appendix B for a list of possible values. 

IMPLEMENTATION 

SOFTPKO 

HREF - indicates the Web page associated with a software distribution. Optional. 

NAME=<string> - the name of the distribution. For a given SOFTPKG, this attribute 

should be a unique identifier The client can use NAME to distinguish one 

SOFTPKG from all others. A software package's "friendly-name" is specified by 

using the TITLE element. 

VERSION-<string> 

DEPENDENCY 

ABSTRACT, CODEBASE, IMPLEMENTATION, DEPENDENCY, TITLE 

TITLE 

<string> 

SOFTPKG 

VM 

VALUE 

IMPLEMENTATION 



[0085] The OSD vocabulary can be used in a stand-alone 
XML manifest file to declare the dependencies between 
different software components for different operating sys- 
tems and languages. The OSD file provides instructions that 
can be used to locate and install only the required software 
components depending on the configuration of the target 
machine and what software is already present. The OSD 
formatted manifest file also can be embedded in an archive 
file, such as a Java Archive (JAR) file, or a composite, 
compressed file, such as a cabinet (.CAB) file, that contains 
the component's distribution unit to form a distribution unit 
file. 

[0086] Additionally, the manifest file can specify an XML 
tag, "namespace/* that causes the package manager to 
isolate software packages from one another even if the same 
component is used by multiple packages: 
[0087] <JAVA> 

[0088] <NameSpace>Fred's Software Company</ 
NameSpace> 

[0089] Thus the use of namespaces avoids version mis- 
matches among software packages. 

[0090] A namespace is analogous to a directory in a file 
system, such as implemented in the Windows family of 
operating systems, in that installing applications in different 
directories provides isolation for the applications. Previ- 
ously a namespace was global to all applications installed on 
a system so that all files and components in the namespace 
were accessible by the applications. The global nature of 
previous namespaces presents difficulties in naming files and 
components because an application programmer has to 
avoid common names to prevent potential conflicts with 
identically named files and components for another appli- 
cation installed in the same namespace. Installing the second 
of the two applications would likely cause one or both 
applications to fail, just as placing all files for all applica- 
tions installed on a computer into a single directory fre- 
quently causes conflicts between the applications. 

[0091] In the present invention, the presence of a 
namespace XML tag in the manifest file causes the package 



manager to associate the files and components of the cor- 
responding application in the code store data structure with 
the unique namespace specified in the tag. When an appli- 
cation is executed, the package manager passes the associ- 
ated namespace name to the computer's runtime environ- 
ment so that any files and components installed in that 
namespace are visible to the application while files and 
components installed in other namespaces are not. Using the 
example XML tag above, Fred's Coolest App is associated 
with a namespace called "Fred's Software Company," 
would execute in the "Fred's Software Company" 
namespace, and have access to any files or components 
installed in the "Fred's Software Company" namespace. 
Similarly, an XML tag for Bob's identically named "Coole- 
stApp" would specify "Bob's Software Company" as the 
namespace, execute in the "Bob's Software Company" 
namespace, and have access to any files or components 
installed in the "Bob's Software Company" namespace. 
Neither Bob's CoolestApp nor Fred's CoolestApp can 
access a common component or file installed in the other's 
namespace. Therefore, because of the isolation that 
namespaces provide, both Fred and Bob are assured their 
applications will function correctly even though identically 
named and having common components or files, and that the 
applications will continue to function correctly irregardless 
of the number of CoolestApps using the same components 
or file which may be installed on the computer. 

[0092] Continuing with the distribution of Fred's Software 
Company's CoolestApp, the manifest file in a first exem- 
plary embodiment in this section is stored separately from 
the distribution unit at http://www.fsc.com/coolestapp.osd. 
The corresponding distribution unit is stored in a cabinet file 
at http://www.fsc.org/coolestapp.cab. The CoolestApp 's 
dependency on the components of the earlier CoolApp is 
indicated with a "DEPENDENCY" tag and refers the pack- 
age manager to the CoolApp manifest file at http://www.f- 
sc.org/coolapp.osd (not shown). The CoolApp manifest file 
directs the package manager to the location of the distribu- 
tion unit for the CoolApp. 
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<SOFTPKO NAME« M com.fsc.www.coolcstapp" VERS ION-" 1,0A0"> 
<TITLE>Coo]cstApp</nTLE> 
<ABSTRACT>CoolcstApp by Fred's 
Software Compaay</ABSTRACT> 
<UCENSE HREF-" http7Avww.fsc.com/ 
coolcstapp/liccnsc.html7> 

<! — FSC's CoolestApp is implemented in native code -> 
<IMPLEMENTATION> 

<OS VALUE-"WinNr , ><OSVERSION 

VALUE-"4,0,0,0"/></OS> 

<OS VALUE-**Wb95*7> 

PROCESSOR VALUE«-' 4 x86 , 7> 

<LANGUAGE VALUE-"en*7> 

<CODEBASE HREF-"nttp ://www.f sao rg/coolestapp.cab'7> 
<! — CoolestApp needs CoolerApp •-> 
<DEPENDENCY> 

<CODEBASE HREF-> M http://www.fscx)rg/ 
coolapp.osd"/> 
^DEPENDENCY > 
^/IMPLEMENTATION 
</SOFTPKG> 



[0093] Had the CoolApp manifest file been stored in a 
cabinet distribution unit file along with the CoolApp com- 
ponents, the location of the distribution unit file would have 
been http://www.fec.org/coolapp.cab. 

[0094] In a second exemplary embodiment of the inven- 
tion for purposes of this section, components contained in a 
distribution unit file are caused to be installed by OSD tags 
embedded on a Web page. If Fred's Software Company's 
Web page requires additional software to be downloaded 
and installed for viewing the page, FSC can use the OSD 
vocabulary within HTML commands to have the user's 
browser download the necessary components as shown in 
the two examples below. 



Company's server to the user's computer. This automatic 
distribution across a network employs "channels" to which 
the user subscribes to automatically "push" software com- 
ponents through a client agent such as a browser. The 
channel is described using a Channel Definition Format 
(CDF) which is also based on XML. A CDF file uses the 
OSD elements to inform a CDF-aware client agent as to 
what software components should be downloaded and 
installed. 



cCHANNEL HREF-"httpy/www.£sc.com.i[itropagc.htiri ,, > 
<SELF-"http i//www.fsc.oo m/fl o ftwnrc. cdT/> 
<TTTLE>A Software Distribution Channel </TITLE> 
<SOFTPKQ 

HREF- M http ;//www. fec.com/aboutsoftware.htm" 
AUTOINSTALL- w ye 5 " 

NAME*» M { D27CDB 6E- AE 6*D- 11 CF-9 6B8-444553540000 }" 

VERSION-*%0,0 ( (r> 
<IMPLEMENTATION> 

<OS VALUE«"WinNT'><OS VERSION 

VALUE-' , 4,0,0.07></OS> 

<OS VALUE«"Win957> 

PROCESSOR VALUE-"jc86*7> 

<CODEBASE HREF- M bltp://www.fsc.com/ 

coolestapp.cab'7> 
IMPLEMENTATION 
</SOFTPKG> 
</CHANNEL> 



[0097] This section has described a particular implemen- 
tation of the package manager which is directed to install 
software by OSD elements embedded in an XML document. 
The processing of a manifest file described in previous 
section when written as XML document is described. In 
addition, alternate embodiments in which a separate XML 
document resides on a Web page to direct a browser to 



cOBJECT CLASSID-"clBid:9DBAFCCF-592F-101 B-85CE-00608CEC297B" 
VERS[ON- H 1,0,0,(T 

CODEBASE-"http ://www.fsc.com/co olestapp .osd" 
HEIGHT- 100 WIDTH«.2O0 > 
</OBJECT> 

-01- 

<APPLET code-myappleUlass id-cooleslapp width=320 height=240> 
<PARAM NAME-us eslibrary VALUE="coo]estapp"> 
<PARAM NAMEouseslibraiyversion VALUE-" 1,0,0,0"> 

<PARAM NAME-us es libra rycodebase VALUE-"httpV/www.fsc.com/coolestapp.osd 

"> 

</APPLET> 



[0095] The HTML <OBJECT> or <APPLET> tag informs 
an OSD-aware client browser, such as Microsoft Explorer 4, 
that there is additional software required to view the Web 
page. The browser invokes the package manager to execute 
the software package if it is already installed or to install it 
if not. If not already installed, the package manager instructs 
the browser to download the distribution file unit and 
proceeds with the installation as described in the previous 
section. The "CODEBASE" element in <OBJECT> and the 
"useslibrarycodebase" tag in <APPLET> can point to the 
manifest file or to the distribution unit file. 

[0096] In a third exemplary embodiment of the invention 
for purposes of this section, a distribution unit file is used to 
automatically distribute software from Fred's Software 



invoke the package manager to install a software package is 
also described in this section. 

[0098] Conclusion 

[0099] A software package manager has been described 
which manages the installation, execution and uninstallation 
of software packages acquired through various media. The 
software manager uses a manifest file, a distribution unit, 
and a code store data structure to accomplish its functions. 
Although specific embodiments have been illustrated and 
described herein, it will be appreciated by those of ordinary 
skill in the art that any arrangement which is calculated to 
achieve the same purpose may be substituted for the specific 
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embodiments shown. This application is intended to cover 
any adaptations or variations of the present invention. 

[0100] For example, those of ordinary skill within the art 
will appreciate that the file and data structures described 
herein can be easily adapted to future distribution media. 
Furthermore, those of ordinary skill within the art will 
appreciate that future extensible languages which are plat- 
form and operating system independent can be used to direct 
the software package managers actions. 

[0101] The terminology used in this application with 
respect to is meant to include all hardware and software 
platforms. Therefore, it is manifestly intended that this 
invention be limited only by the following claims and 
equivalents thereof. 

We claim: 

1. In a computer, a method of processing one or more 
software dependencies, the method comprising: 

for one or more of the software dependencies, determin- 
ing whether software associated with the software 
dependency is present on the computer; and 

responsive to determining the software associated with 
the software dependency is not present on the com- 
puter, acquiring the software associated with the soft- 
ware dependency; 

wherein at least one of the software dependencies refers 
to a list comprising one or more other software depen- 
dencies. 

2. The method of claim 1 wherein acquiring the software 
associated with the software dependency comprises acquir- 
ing a file comprising the list comprising one or more other 
software dependencies. 

3. The method of claim 1 wherein acquiring the software 
associated with the software dependency comprises acquir- 
ing a list of one or more files from a remote location and 
acquiring the files in the list. 

4. The method of claim 1 wherein one or more of the 
software dependencies is associated with a location whereat 
the list of other software dependencies can be found. 

5. The method of claim 1 further comprising: 

after acquiring the software associated with the software 
dependency, updating a database at the computer indi- 
cating the software associated with the software depen- 
dency is installed on the computer, wherein the data- 
base is operable to indicate whether a plurality of 
software components are installed via a single name 
associated with the plurality of software components. 

6. The method of claim 1 further comprising: 

after acquiring the software associated with the software 
dependency, updating a database at the computer indi- 
cating the software associated with the software depen- 
dency is installed on the computer, wherein the data- 
base is operable to indicate whether a plurality of 
software dependencies are installed via a single name 
associated with the plurality of software dependencies. 

7. The method of claim 1 wherein: 

one or more dependencies in the list of software depen- 
dencies is associated with a version number, and 



determining the dependency is not present on the com- 
puter comprises determining software satisfying the 
version number is not present on the computer. 

8. The method of claim 7 wherein at least two software 
dependencies are associated with different version numbers. 

9. The method of claim 1 wherein at least one of the 
dependencies specifies a plurality of software items forming 
a software package. 

10. The method of claim 9 wherein the software package 
comprises a mixture of native code components and Java 
classes. 

11. The method of claim 1 wherein acquiring dependen- 
cies is deferred until execution of software associated with 
the dependencies is requested. 

12. A computer-readable medium comprising computer- 
executable instructions for performing at least the following 
to process one or more software dependencies in a com- 
puter: 

for one or more of the software dependencies, determin- 
ing whether software associated with the software 
dependency is present on the computer; and 

responsive to determining the software associated with 
the software dependency is not present on the com- 
puter, acquiring the software associated with the soft- 
ware dependency; 

wherein at least one of the software dependencies refers 
to a list comprising one or more other software depen- 
dencies. 

13. In a computer, a method of specifying a software 
dependency, the method comprising: 

specifying a name of the software dependency; 

wherein the name is operable to identify a list of one or 
more other software dependencies. 

14. The method of claim 13 wherein the software depen- 
dency is indicated by a name, and the name is associated 
with a software package comprising a plurality of software 
components. 

15. The method of claim 13 wherein the software depen- 
dency is associated with a software package depending on at 
least one other software package. 

16. The method of claim 13 wherein the software depen- 
dency is indicated by a version, the method further com- 
prising: 

comparing the version for the software dependency 
against a version of software installed at a computer; 
and 

responsive to determining the version installed at the 
computer is not sufficient, acquiring the version for the 
software dependency. 

17. In a computer, a method of processing a name 
designating software, the method comprising: 

consulting a database to see if software associated with 
the name is already installed at the computer; and 

responsive to determining software associated with the 
name is not already installed at the computer, acquiring 
the specified software; 

wherein the name is operable to specify a plurality of 
software components. 
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18. The method of claim 17 wherein the plurality of 
software components is divided among a plurality of files. 

19. The method of claim 17 wherein the plurality of 
software components comprises a plurality of files. 

20. The method of claim 17 wherein 

the name is operable to specify a plurality of different 
software components; and 

different versions are associated with the different soft- 
ware components. 

21. The method of claim 17 wherein acquiring the speci- 
fied software comprises recursively processing software 
dependencies associated with the name to find one or more 
other software dependencies associated with names desig- 
nating software. 

22. The method of claim 17 wherein the name is operable 
to specify a list of one or more software dependencies, the 
method farther comprising: 

for at least one software dependencies, determining soft- 
ware associated with the dependency is already 
installed at the computer, wherein the dependency 
specifies a plurality of software components. 

23. The method of claim 17 wherein acquiring the speci- 
fied software comprises identifying an other name associ- 
ated with a plurality of software components, and acquiring 
the plurality of software components associated with the 
other name. 

24. A computer-readable medium comprising a computer 
software package of a nestable software package format, 
wherein the software package format comprises: 

a package name; 

a list of dependencies, wherein the list of dependencies is 
operable to specify one or more other software pack- 
ages on which the software package depends, wherein 
at least one of the other software packages is associated 
with another package name and another list of depen- 
dencies and is also of the nestable software package 
format. 

25. The computer-readable medium of claim 24 wherein 
the nestable software package format is operable to specify 
one or more components required by the software package. 

26. The computer-readable medium of claim 24 wherein 
the nestable software package format is operable to specify 



a remote location from which one or more components 
required by the software package can be obtained. 

27. A computer-readable medium comprising a software 
distribution package for installing software at a computer, 
wherein the software distribution package comprises: 

one or more items for installation at the computer; 

a dependency list indicating one or more items depended 
on by the software, wherein at least one of the items on 
the dependency list is not contained in the package, and 
the software package indicates a remote location from 
which the item can be obtained; 

wherein the items are specified in the dependency list by 
a name operable to specify a plurality of additional 
items. 

28. A computer system for executing a software package 
comprising a specified list of one or more dependencies, the 
computer system comprising: 

a database indicating the installation status of one or more 
software components; 

a software package manager operable to resolve the 
specified list of one or more dependencies by consult- 
ing the database to determine whether a dependency is 
installed and further operable to acquire a dependency 
determined as not installed; 

wherein the software package manager is operable to 
process at least one item in the specified list of depen- 
dencies referring to an other list of dependencies. 

29. The computer system of claim 28 wherein the soft- 
ware package manager is further operable to acquire a file at 
a remote location indicating the other list of dependencies. 

30. The computer system of claim 28 wherein the other 
list of dependencies is specified via an URL. 

31. The computer system of claim 28 further comprising 
a browser; 

wherein the software package manager is operable to 
initiate execution of a software package as directed by 
the browser upon encountering HTML tags indicating 
the specified list of dependencies. 

***** 
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